Gateway Selection Mechanism

ABSTRACT

An arrangement and method in a Public Land Mobile Network (PLMN) for selecting a gateway to connect a User Equipment (UE) to a home PLMN when the UE is located in an access network connected to a visited PLMN. The arrangement receives a first Fully Qualified Domain Name (FQDN), which includes an identity of the UE user. Based on the identity of the user and knowledge of the visited PLMN, the arrangement selects whether the UE should establish a connection only to a gateway in the home PLMN, only to a gateway in the visited PLMN, or both. The arrangement transmits to the UE, an appropriate address for the home PLMN gateway, the visited PLMN gateway, or both depending on the selection.

TECHNICAL FIELD

The present invention relates to a mobile communication network and inparticular, to a gateway selection mechanism e.g. forInterworking-Wireless Local Area Network (I-WLAN) and evolutions of theUniversal Mobile Telecommunications System (UMTS).

BACKGROUND

The invention relates to the interworking of Third GenerationPartnership Project (3GPP) Public Land Mobile Networks (PLMNs) i.e.General Packet Radio Service/Universal Mobile Telephony System(GPRS/UMTS) and Wireless Local Area Network (WLAN) access networks,commonly known as I-WLAN. It also relates to the planned/anticipatedevolution of the current 3GPP network (i.e. GPRS/UMTS) architecture intoa somewhat simplified and more multi-access oriented form, as beingworked out by the 3GPP. This evolution and its related activities in the3GPP are commonly referred to as System Architecture Evolution (SAE).

I-WLAN is being specified by the 3GPP and the functional description isprovided in 3GPP TS 23.234 v6.4.0, 3^(rd) Generation PartnershipProject; Technical Specification Group Services and System Aspects; 3GPPsystem to Wireless Local Area Network (WLAN) interworking; Systemdescription (Release 6).

One of the I-WLAN scenarios specified by the 3GPP is the WLAN 3GPP IPAccess. FIG. 1 a shows a reference model of the roaming variant of theWLAN 3GPP IP Access, where a WLAN Access Network 100 is connected to a3GPP Visited Network 110. A WLAN User Equipment (UE) 120, i.e. theI-WLAN terminal also referred to as a user terminal, is located in anarea controlled by the WLAN access network 100 connected to the visitednetwork 110. The UE 120, which can also be called user terminal or justterminal, has a further connection to the home network 130, i.e. to agateway 140, referred to as the Packet Data Gateway (PDG), via the Wuinterface 150. Although this connection physically goes via the WLANaccess network 100 and the visited network 110, it is depicted in FIG. 1a as a direct line between the UE 120 and the PDG 140, because the linerepresents the logical interface between the UE 120 and the PDG 140. TheWLAN access network 100 has connections to the gateway 160 of thevisited network 110, referred to as WLAN Access gateway (WAG) via the Wninterface 170 and to an Authentication, Authorization and Accounting(AAA) proxy 180 via the Wa interface 210. The WAG 160 is also connectedto the AAA proxy 180 via the Wg interface 200. The gateways of the homeand the visited networks are connected via the Wp interface 190.Moreover, the AAA proxies of the home and the visited network areconnected via the Wd interface 220. The entities of FIG. 1 a notdescribed are not relevant for the invention and are only included togive a more complete picture of the network architecture.

In the context of this invention only a scenario denoted WLAN 3GPP IPAccess scenario is of interest and therefore the WLAN 3GPP IP Accessscenario is assumed in all further descriptions, unless explicitlystated otherwise.

In the WLAN 3GPP IP Access scenario the traffic between an I-WLANterminal accessing a WLAN access network and a peer on the Internet istunneled between the terminal and the home PLMN, via the WLAN accessnetwork and the visited PLMN, and routed between the tunnel endpoint inthe home PLMN and the peer on the Internet. This is referred to as hometunneling. As an option the traffic may instead be tunneled between theI-WLAN terminal and the visited PLMN, without involving the home PLMN inthe traffic processing, which is referred to as local breakout.

The tunnel traverses the Wn and Wp interfaces. When traversing the Wninterface the tunnel may traverse untrusted networks with unknowncapabilities, e.g. the Internet. On the Wp interface the traversednetworks are regarded as secure, either operator internal networks orthe inter-operator network GPRS roaming exchange (GRX).

The tunnel endpoint in the home or visited PLMN is a gateway, either thePDG or the Tunnel Terminating Gateway (TTG) These two nodes should beregarded as alternative implementations where in the TTG case the PDGfunctionality is split between the TTG and the GGSN, but theoreticallyit would be possible to have both types of implementations in the samenetwork.

When an I-WLAN terminal attempts to access a WLAN access network, theWLAN access network has the option to authenticate the user beforegranting the access. If the WLAN access network chooses to use thisoption (which will probably be more common than the opposite), it usesthe Authentication, Authorization and Accounting (AAA) infrastructure toauthenticate the identity of the user, aided by the AAA server in theuser's home PLMN. The authentication mechanism is either EAP-AKA asdescribed in J. Arkko, H. Haverinen, “Extensible Authentication ProtocolMethod for 3^(rd) Generation Authentication and Key Agreement (EAP-AKA),RFC 4187, January 2006 or EAP-SIM as described in H. Haverinen, J.Salowey, “Extensible Authentication Protocol Method for Global Systemfor Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)”,RFC 4186, January 2006, which is communicated transparently between theterminal and the home AAA server, via the AAA proxy in the visited PLMNin the roaming case.

When the user is permitted access to the WLAN access network (whetherauthenticated or not), the terminal uses Internet Key Exchange version 2(IKEv2), further described in Charlie Kaufman et al., “Internet KeyExchange (IKEv2) Protocol”, RFC 4306, December 2005, to establish anIPsec tunnel, further described in S. Kent, Rt. Atkinson, “SecurityArchitecture for the Internet Protocol”, RFC 2401, November 1998, and S.Kent, K. Seo, RFC 4301, with the same title, to the PDG/TTG in the homePLMN via the WAG in the selected visited PLMN. Optionally, the IPsectunnel may be established between the terminal and the PDG/TTG in thevisited PLMN instead of the PDG/TTG in the home PLMN. The terminal usesthe WLAN Access Point Name (W-APN), which is stored in the SubscriberIdentity Module (SIM) or the Universal Subscriber Identity Module (USIM)(on the Universal Integrated Circuit Card (UICC)), to determine the IPaddress of the PDG/TTG to be used as the remote tunnel endpoint. TheW-APN, which constitutes a domain name consisting of a NetworkIdentifier and an Operator Identifier (in that order), is resolved intoan IP address through regular Domain Name System (DNS) mechanisms.

In IKEv2 EAP-AKA or EAP-SIM is used as an integrated mechanism toauthenticate the user to the PDG/TTG during the tunnel establishment.The PDG/TTG communicates with the AAA server in the home network via aAAA protocol, preferably Diameter e.g. described in Pat Calhoun et al.,“Diameter Base Protocol”, RFC 3588, September 2003, and P. Eronen etal., “Diameter Extensible Authentication Protocol (EAP) Application”,RFC 4072, August 2005, to have the user authenticated.

When the IPsec tunnel is established, the PDG/TTG assigns an “inner” IPaddress to the terminal.

If the tunnel endpoint in the PLMN is a TTG, then the TTG alsoestablishes a GTP tunnel to the GGSN and associates the IPsec tunnel andthe GTP tunnel with each other. Then the regular traffic through thetunnel(s) can commence.

The basic tasks of the WLAN Access Gateway (WAG) in addition to routingpackets between the WLAN access network and the PDG/TTG include:

-   -   Count packets and generate accounting data when the PDG/TTG is        located in another network.    -   Simple packet filtering based on unencrypted information in the        IP header. The packet filters are derived from policy        enforcement information transferred to the WAG 160 (over the Wg        interface) from the home AAA servers 230 of the concerned        subscribers (via the Wd 220 interface and the AAA proxy 180 in        case the WAG is located in the visited PLMN).

Selection of PDG/TTG is provided via DNS based on a Fully QualifiedDomain Name (FQDN) derived from the W-APN and the PLMN ID (i.e. theHPLMN ID or the VPLMN ID). When a TTG is used, the Network ServiceAccess Point Identifier (NSAPI) allocation requires that for a givenuser, all tunnels towards W-APNs served from the same GGSNs should bedirected to the same TTG.

One long-term target architecture that has been considered in thearchitecture evolution work includes an overall multi-access corenetwork with AENs (Access Edge Nodes) at the edges according to FIG. 1b. An AEN is thought of as an evolution of an advanced version of a GPRSSupport Node labeled “GSN+”. A GSN+ 430 is in turn an evolved version ofthe GPRS Support Node (GSN) in the current 3GPP network architecture.FIG. 1 b illustrates a Home network 300 comprising an AEN 310 and policyand charging control functions 320 and a visited network 400 alsocomprising an AEN 410 and policy and charging control functions 420. Aroaming interface 440 is provided between the home and the visitednetwork. The AEN of the visited network is further connected todifferent access networks such as Wideband Code Division Multiple Access(WCDMA), Global System for Mobile communications/Enhanced Data rates forGSM Evolution (GSM/EDGE), Public WLAN and various variants of DigitalSubscriber Line (xDSL, where x can represent various letters, such as Afor “Asymmetric”, S for “Symmetric”, H for “High speed” or V for “Veryhigh speed”) access networks. The AENs comprise common accessindependent (but to a certain extent “access aware”) functionality thatis used for all accesses. In addition there is an access dependent partfor each specific access technology served by an AEN. An AEN may berealized as multiple cooperating nodes.

Regarding I-WLAN the evolution strategy is to simplify the architectureand to incorporate the nodes/functions more closely into the general3GPP architecture than in the current specifications. In the long-termtarget architecture it is proposed that the PDG/TG and the WAG be mergedinto the AEN. Possible intermediate stages may include that the PDG/TTGis merged into future evolved GPRS support nodes (GSN+), that thePDG/TTG and the WAG are merged into future evolved GPRS support nodes(GSN+) or even that the PDG/TTG and the WAG are merged. The view of theevolved future network architecture is not stable yet and hence theresult of this work in the 3GPP may well be something that is differentfrom what is illustrated in FIG. 1 b. Another proposed evolved networkarchitecture is illustrated in FIG. 1 c. The AEN in the evolved networkarchitecture as depicted in FIG. 1 b is more or less equal to acombination of nodes referred to as the Inter Access System Anchor(IASA), the Mobility Management Entity (MME) and the User Plane Entity(UPE) in the evolved network architecture illustrated in FIG. 1 c. FIG.1 c illustrates the scenario when both home routed traffic and localbreakout traffic are routed via the visited Inter AS Anchor (v-IASA) inthe roaming case. It should be noted that the AAA server is assumed tobe integrated in the Home Subscriber Server (SS). The visited networkcomprises a GPRS core network 530 and an Evolved Packet Core (EPC) 500comprising the IASA 520 and the MME 510 and the UPE 510. The visitedGPRS core network 530 is connected to a plurality of different accessnetworks such as GSM EDGE radio access network (GERAN), UMTS TerrestrialRadio Access Network (UTRAN) and evolved Radio Access Network (evolvedRAN) while the IASA 520 of the visited EPC 500 is connected to a WLANwhich is of interest for the present invention. The visited IASA 520 isconnected to a policy control resource function 540 of the visitednetwork, to the HSS 620 of the home network and to the IASA 610 of thehome EPC 600.

In SAE, which extends the system to multi-access (through heterogeneousaccesses), two “tiers” of mobility management are assumed: one tier forthe inter access mobility (i.e. mobility between access networks ofdifferent types) and one tier for the “internal” mobility in the 3GPPdomain. Both tiers utilize anchor nodes as a stable point for thetraffic. The Inter Access System Anchor (IASA) is the anchor node forthe inter-access mobility and the User Plane Entity (UPE) is the anchornode for the intra-3GPP domain mobility. The UPE is a pure user planenode and it is complemented by the Mobility Management Entity (MME)which handles the control plane for the intra-3GPP domain mobilitymanagement (as well as other access related signaling).

In FIG. 1 c, the roaming with home tunneling case involves two IASAnodes, one visited IASA (v-IASA) in the visited PLMN and one home IASA(h-IASA) in the home PLMN. In this description the IASA that is closestto the terminal/UE is denoted “serving IASA” (s-IASA). In thenon-roaming case the s-IASA is the h-IASA and in the roaming with localbreakout case the s-IASA is the v-IASA. In the architecture illustratedin FIG. 1 c the s-IASA is the v-IASA in all roaming cases, both forlocal breakout and for home tunneling/home routing.

The SAE architecture includes an anchor node for inter-access systemmobility. This anchor node is assumed to be a Mobile IP (MIP) Home Agent(HA). Preferably it is a Mobile IPv6 (MIPv6) HA, but it may also turnout to be a Mobile IPv4 (MIPv4) HA. The HA will probably be integratedin, or co-located with, the h-IASA. Whether the h-IASA corresponds to asingle HA or multiple (e.g. for redundancy or load sharing purposes) isnot decided and may not have to be specified at all.

Local breakout in I-WLAN, i.e. the scenario when the UE-PDG/TTG tunnelis established between the UE and PDG/TTG in the visited PLMN(henceforth denoted PDGv/TTGv), is possible also in the current I-WLANsolution, to a certain extent under the control of the home operator.

To select local breakout the user/UE constructs an FQDN using the W-APNNetwork Identifier and the VPLMN ID as the Operator Identifier andperforms a DNS query to resolve the FQDN into one or several PDGv/TTGvIP addresses) (i.e. using information originating in a DNS server in theVPLMN). It should be noted that the terms “DNS server”, “DNS nameserver” and “name server” are regarded as synonyms in this description.Then the IPsec tunnel is established between the UE and the PDGv/TTGvusing IKEv2 and with the home AAA server authenticating and authorizingthe user/UE.

To select home tunneling (the basic case i.e. non-local breakout) theuser/UE constructs an FQDN indicating the HPLMN.

When local breakout is used, the HPLMN authorizes the local breakoutthrough the AAA communication between the PDGv/TTGv and the home AAAserver. If the policy of the HPLMN does not allow local breakout (forthis user, W-APN, VPLMN or any combination of these), then the home AAAserver sends a rejection message to the PDGv/TTGv, which in turn rejectsthe tunnel establishment. The user/UE may then start the W-APNresolution and tunnel establishment procedure all over again using anFQDN indicating the HPLMN.

If the user/UE has selected home tunneling, but the policy of the HPLMNmandates/prefers local breakout, then the home AAA server can eitherreject the tunnel establishment or accept it in spite of the policy. Ifthe tunnel establishment is rejected, the UE will not retry tunnelestablishment towards the VPLMN according to 3GPP TS 23.234 v6.4.0,3^(rd) Generation Partnership Project; Technical Specification GroupServices and System Aspects; 3GPP system to Wireless Local Area Network(WLAN) interworking; System description (Release 6)”.

The home AAA server may provide the PDG and the WAG with packet filterinstructions. When a TTG is used the intention is to reuse the packetfiltering functionality of the GGSN, but nothing prevents that the homeAAA server still provides the TTG with packet filter instructions. Whenthe PDG/TTG and/or WAG is located in the VPLMN, the home AAA serverprovides the packet filter instructions via the AAA proxy in the VPLMN.

As mentioned above, in the TTG case it is required that for a givenuser, all tunnels towards W-APNs served from the same GGSNs should bedirected to the same TTG. Currently there is no existing solution forthis. The TTG address is selected and returned via DNS solely based onthe FQDN that is derived from a W-APN and a PLMN ID. There is no userinformation available to aid the TTG IP address selection.

The allocation of the serving IASA (or AEN) when a non-3GPP access (oran evolved I-WLAN access) is used is to a large extent still an openissue. The s-IASA is supposed to be selected/allocated by an access nodein the access network, generally denoted Access Gateway (AGW), based onthe user ID and policies. This is a very high-level assumption withoutany technical details provided.

Allocation of a Mobile IPv6 Home Agent is assumed to be performed viaDNS, according to the principles put forth by the IETF Mobility for IPv6working group in J. Giaretta “Mobile IPv6 bootstrapping in splitscenario”, internet-Draft: draft-ietf-mip6-bootstrapping-split-02, March2006.

The UE uses the regular DNS mechanisms to resolve an FQDN associatedwith its Home Agent and the DNS system returns an IP address of anallocated Home Agent. There are two ways to go about, denoted the “HADNS lookup by name” method and the “HA DNS lookup by service” methodrespectively.

If the UE is configured with an FQDN of a Home Agent, it sends a DNSquery with the QNAME set to the HA FQDN, e.g. “ha.home-operator.com”,and the QTYPE set to “AAAA”. In response the DNS server returns an IPaddress belonging to the Home Agent. This is the “HA DNS lookup by name”method.

The UE does however not have to be configured with an FQDN of a HomeAgent. It is enough that it is configured with an FQDN representing itshome operator, e.g. “home-operator.com”. In such case the UE sends a DNSquery with the QNAME set to mip6._ipv6.home-operator.com” and the QTYPEset to “SRV” (indicating a request for a service resource record). Inresponse the DNS server returns a list of one or more FQDNs belonging tothe available Home Agents, of which the UE selects one. The DNS servermay also include the IP addresses of the Home Agents in addition to theFQDNs. Otherwise the UE has to request the DNS system to resolve theFQDN of the selected HA into an IP address as described for the “HA DNSlookup by name” method. This is the “HA DNS lookup by service” method.

The same methods may be used for allocation of a Mobile IPv4 Home Agent,when a co-located care-of address is used (i.e. when no Foreign Agent isused). When a Foreign Agent is used, the Foreign Agent could use theabove methods to have a Home Agent allocated on behalf of the UE.

In the context of HPLMN controlled local breakout, the initial choice ofwhether to use local breakout or home tunneling lies entirely with theuser/UE. The HPLMN can only accept or reject this choice through the AAAprotocol.

A rejection of local breakout can also be seen as an implicitredirection of the local breakout tunnel to a home tunnel, since therejection will cause the UE to attempt a new tunnel establishment byusing a new FQDN towards the home network.

A rejection of home tunneling will not cause an implicit redirection toa local breakout tunnel. Thus, rejection of home tunneling in practicemeans that network access is rejected (except for possible WLAN DirectIP Access traffic).

Hence, the HPLMN can only affect the initial choice of the user/UE inone direction, i.e. from local breakout to home tunneling, not the otherway around. In addition, the implicit means that the HPLMN has toredirect the UE from local breakout to home tunneling, i.e. rejectiontriggering a new tunnel establishment attempt to the home network, isinefficient and slow, significantly increasing the access delay. IPsectunnel establishment using IKEv2 is not a very swift procedure.Therefore, rejecting one tunnel establishment procedure to initiate anew one (with preceding DNS procedure) introduces a delay that the usermay perceive as inconvenient. Moreover, the redundant double tunnelestablishment procedure unnecessarily consumes resources in the involvednetworks.

A problem with the s-IASA selection mechanism is that there are nodetails provided beyond the statement that the AGW selects the s-IASAbased on user-ID and policy.

A problem with the currently proposed solution for HA allocation in SAEis that it provides the HPLMN with very poor means for flexibleselection of the HA. It basically enables no other flexibility than aplain load-sharing scheme. It completely lacks means for HAselection/allocation based on relevant information, such as policies,user specific conditions, VPLMN, etc.

SUMMARY

Thus, it would be desirable to achieve a solution where the HPLMN isallowed to make the decision whether local breakout should be selected,since the HPLMN is aware of policies and other properties that arerelevant when making the decision.

Thus an object with the present invention is to achieve an improvedsolution for determining whether local breakout or home tunneling shouldbe used when a mobile terminal is to be connected to a WLAN accessnetwork of a visited network.

That is achieved according to a first aspect by an arrangement in a PLMNfor selecting a gateway to which to connect a UE, located in an accessnetwork connected to a visited PLMN of the UE. The PLMN is a home PLMNof the user of the UE. The arrangement comprises means for receiving afirst Fully Qualified Domain Name, FQDN, wherein the first FQDNcomprises an identity of the user of the UE, and the home PLMN is awareof an identity of the visited PLMN. The arrangement comprises means forselecting, at least based on the received identity of the user, whetherthe UE should establish connection only to a gateway, e.g. a PDG/TTG, inthe home PLMN, only to a gateway in the visited PLMN or to both agateway in the home PLMN and a gateway in the visited PLMN and means fortransmitting an address belonging to a gateway in the visited PLMN ifconnection only to a gateway in the visited PLMN is selected or anaddress belonging to a gateway in the home PLMN if connection only to agateway in the home PLMN is selected or addresses belonging to both agateway in the home PLMN and a gateway in the visited PLMN if connectionto both is selected.

According to a second aspect, the UE comprises means for including anidentity of the UE into the first FQDN, and means for receiving anaddress to a gateway in the visited PLMN if the home PLMN has selectedthat the UE should connect to a gateway in the visited PLMN or/and anaddress to a gateway in the home PLMN if the home PLMN has selected thatthe UE should connect to a gateway in the home PLMN at least based onthe identity of the UE.

According to a third aspect, a method in a PLMN for selecting a gatewayto which to connect a UE located in an access network connected to avisited PLMN of the UE, wherein the PLMN is a home PLMN of the UE isprovided. The PLMN receives a first FQDN comprising an identity of theUE and the home PLMN is aware of an identity of the visited PLMN.

At least based on the received identity of the user the PLMN selectswhether the UE should establish connection only to a gateway in the homePLMN, only to a gateway in the visited PLMN or to both a gateway in thehome PLMN and a gateway in the visited PLMN. Therefore, the PLMNtransmits an address belonging to a gateway in the visited PLMN, ifconnection only to a gateway in the visited PLMN is selected, or anaddress belonging to a gateway in the home PLMN, if connection only to agateway in the home PLMN is selected, or addresses belonging to both agateway in the home PLMN and a gateway in the visited PLMN if connectionto both is selected.

According to a fourth aspect, a method in a UE is provided comprisingthe steps of including an identity of the UE into the first FQDN, andreceiving an address to a gateway in the visited PLMN if the home PLMNhas selected that the UE should connect to a gateway in the visited PLMNor/and an address to a gateway in the home PLMN if the home PLMN hasselected that the UE should connect to a gateway in the home PLMN atleast based on the identity of the UE.

According to a preferred embodiment, the means for selecting furthercomprises means for identifying, based on the user identity, one or morevalid policies which govern the outcome of the selecting.

According to a fifth aspect an arrangement in a PLMN for selecting agateway to which to connect a UE located in an access network connectedto a visited PLMN of a UE, wherein the PLMN is a home PLMN of the UE, isprovided. The arrangement comprises means for receiving a first FQDN,wherein the first FQDN comprises an identity of the UE and the home PLMNis aware of an identity of the visited PLMN. The arrangement comprisesmeans for selecting based on the received identity of the user that theUE should establish connection only to a gateway in the visited PLMN,means for transmitting by a home PLMN DNS server a CNAME resource recordcomprising a third FQDN to be used instead of the first received FQDNand to be sent to a visited PLMN DNS server, whereby the third FQDN isconstructed by means of a W-APN network identifier and the identity ofthe visited PLMN, such that the visited PLMN DNS server can send agateway address to the UE by resolving the third FQDN.

According to sixth aspect an arrangement in a UE for determining agateway to connect to, wherein the UE is located in an access networkconnected to a visited PLMN of a UE and the UE belongs to a home PLMN isprovided. The arrangement comprises means for including a first FQDNthat comprises a domain name belonging to the home PLMN into a DNSrequest, means for including an identity of the visited PLMN into thefirst FQDN, and means for receiving an address to a gateway in thevisited PLMN if the home PLMN has selected that the UE should connect toa gateway in the visited PLMN or/and an address to a gateway in the homePLMN if the home PLMN has selected that the UE should connect to agateway in the home PLMN at least based on the identity of the visitedPLMN of the UE.

Thus, a main advantage achieved by the present invention is that theHPLMN is allowed to make the decision whether local breakout should beselected. This is advantageous since the HPLMN is aware of policies andother properties that are relevant when making the decision.

Another advantage is that the solution according to an embodiment canalso be used to provide a mechanism that in the TTG case ensures thatfor a given user, all tunnels towards W-APNs served from the same GGSNsbe directed to the same TTG.

A further advantage is that the solution according to an embodiment canbe extended with flexible support for simultaneous local breakout andhome tunneling using dual tunnels, one local breakout tunnel and onehome tunnel. Selection of which tunnel to use is made on a per packetbasis (although in practice it will be equivalent to per flow basis)using packet filters.

A further advantage is that the solution can also be used in stepwiseevolved scenarios, where the IPsec tunnel endpoint is moved to the WAGor the AEN (or an AEN like node e.g. a GSN+) (with the PDG/TTG functionsmerged into the AEN/GSN+).

A further advantage is that the present invention according toembodiments allows DNS indication of PDG/TTG (or GSN+ or AEN) on a W-APNand user identity basis instead of based on the W-APN only, i.e. theflexibility of the control means is increased.

A further advantage is that the solution is transparent to the WLANaccess network and the visited 3GPP network (VPLMN), affecting only thehome network (HPLMN) and the terminal/UE.

A further advantage is that the solution may be provided to an operatorwithout standardization, provided that both the solution's home networkcomponents and its terminal components (as customized terminals orpossibly as downloadable software) are delivered from the same vendor.

A further advantage is that the solution also may be used in other typesof non-3GPP access networks than WLAN, provided that the I-WLANtunneling solution is used for interworking between the access networkand a 3GPP PLMN.

A further advantage is that the basic concept of the solution may bereused in an AEN selection/allocation procedure in one of the long-termevolved network architectures that has been considered for the evolutionof 3GPP networks.

A yet further advantage is that the basic concept of the solution may bereused in a s-IASA selection/allocation procedure in another of thelong-term evolved network architectures considered for 3GPP SAE.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 a illustrates I-WLAN wherein the present invention may beimplemented.

FIG. 1 b illustrates one of the long-term target network architecturesthat has been considered for 3GPP SAE (the one which incorporates AENs),wherein the present invention may be implemented.

FIG. 1 c illustrates one of the long-term target network architecturesthat has been considered for 3GPP SAE (the one which incorporatesIASAs), wherein the present invention may be implemented.

FIGS. 2 to 6 are signal diagrams showing embodiments of the presentinvention.

FIG. 7 illustrates schematically the arrangements of the presentinvention.

FIGS. 5 a and 5 b are flowcharts of the methods according to the presentinvention.

DETAILED DESCRIPTION

The basic mechanisms of the solution are described in the context oflocal breakout in I-WLAN. More or less the same mechanisms are reusedfor the other applications of the invention, i.e. selection/allocationof AEN/s-IASA and HA/h-IASA in the evolved 3GPP multi-accessarchitecture.

The basic concept is to move the choice of DNS server, and thus thechoice of local breakout or home tunneling, from the user/UE to theHPLMN, since the HPLMN can, based on its policies, choose local breakoutor home tunneling. If the HPLMN chooses local breakout, it may retrievethe required PDGv/TTGv address(es) from the VPLMN. When choosing betweenhome tunneling and local breakout the HPLMN may consider any relevantinput data, such as W-APN, subscription parameters, VPLMN and possiblyother parameters such as location, time of day etc.

The movement of the selection of home tunneling versus local breakout isachieved by mandating that the user/UE always constructs an FQDN thatindicates the HPLMN, i.e. it should construct an FQDN using the W-APNNetwork Identifier and the HPLMN ID as the Operator Identifier. Whilesuch a “home FQDN” indicates the HPLMN, and would cause a DNS query tobe resolved by the HPLMN, it does not contain enough information for theHPLMN to make policy based decision on whether to use home tunneling orlocal breakout.

In order for the HPLMN to be able to apply the correct policy, it mustknow the identity of the user that originates the DNS request.Therefore, the user/UE includes the user ID in the FQDN in the DNSrequest in accordance with the present invention. The user ID may beincluded before the regular home FQDN, giving it the format <userID>.<regular home FQDN>. It is also possible to clearly separate the twoparts with a dedicated delimiter string, e.g. “zzzz”, resulting in theformat <user ID>.<delimiter string>.<regular home FQDN>.

It is then the choice of the HPLMN to return one or more IP address(es)of one or more PDGs/TTGs in either the HPLMN (i.e. if home tunneling isselected) or the VPLMN (i.e. if local breakout is selected). In theformer case the DNS server in the HPLMN can form the response. In thelatter case the HPLMN modifies the received FQDN and sends it in a DNSrequest to the VPLMN in order to retrieve one or more IP address(es) ofone or more PDGs/TTGs in the VPLMN, which then is(are) included in theDNS response from the HPLMN. It should be noted that “DNS request” isused herein as a synonym of the more commonly used term “DNS query”.

Further, the HPLMN must be aware of the identity of the concerned VPLMN.There are two reasons for that. The first reason is that it may affectthe outcome of the policy decision (i.e. local breakout or hometunneling). The second reason is that in case local breakout is chosen,the HPLMN needs to know from which VPLMN to retrieve the PDGv/TTGvaddress(es). In one embodiment of the invention the UE is adapted toinclude the VPLMN ID in the FQDN in order to inform the HPLMN, e.g.after the user ID, so that the format becomes <user ID>.<VPLMNID>.<regular home FQDN> or <user ID>.<delimiter string>.<VPLMNID>.<delimiter string>.<regular home FQDN>. In another embodiment of theinvention the VPLMN ID is not included in the FQDN. Instead the VPLMNidentity is retrieved by the HPLMN during a preceding WLAN access AAAprocedure for the concerned user (indicated by the user ID in the FQDN)in order to find out which the concerned VPLMN is. The latter embodimentobviously requires that the optional access authentication in the WLANaccess network has been performed.

When the UE has received the PDG/TG IP address(es) the subsequent IPsectunnel establishment procedure is the same as in the existing solution.

The user ID in the FQDN could be either only the name part of the NAI orthe full NAI. The former case can be used if the name part alone isunambiguous, i.e. in principle if the HPLMN uses the same realm part forall its users. In the latter case the “@” character, which is not anallowed character in an FQDN, can be replaced by a dedicated delimiterstring, e.g. “.at.”. A name part ending with “.at” and a realm partbeginning with “at.” could then potentially cause ambiguity. To avoidthis risk it can be allowed to have either the name part ending with“.at” or the realm part beginning with “at.”, but both cannot beallowed. The easiest is to keep the flexibility in the name part (i.e.allowing the name part to end with “.at”) and let the home operatorensure that no valid realm (that can constitute the realm part of a NAI)begins with “at.”.

Thus, the present invention provides an arrangement 900 illustrated inFIG. 7 to be implemented in one or more nodes 904 in a PLMN 905 forselecting a gateway to which to connect a UE 906 located in an accessnetwork connected to a visited PLMN of a UE, wherein the PLMN is a homePLMN of the user of the UE. That implies that the UE comprises a SIMcard, whereby the user registered to the SIM-card belongs to the homePLMN. The arrangement comprises means 901 for receiving a first FQDN,whereby the first FQDN comprises an identity of the user of the UE. Thehome PLMN is aware of an identity of the visited PLMN. The arrangementcomprises means for selecting 902, at least based on the receivedidentity of the user, whether the UE should establish connection only toa gateway in the home PLMN, only to a gateway in the visited PLMN or toboth a gateway in the home PLMN and a gateway in the visited PLMN andmeans for transmitting 903 an address belonging to a gateway in thevisited PLMN if connection only to a gateway in the visited PLMN isselected or an address belonging to a gateway in the home PLMN ifconnection only to a gateway in the home PLMN is selected or addressesbelonging to both a gateway in the home PLMN and a gateway in thevisited PLMN if connection to both is selected.

Further, the invention relates to an arrangement in a UE comprisingmeans for including 907 a first FQDN that comprises a domain namebelonging to the home PLMN into a DNS request, means for including 908an identity of the user of the UE into the first FQDN, and means forreceiving 909 an address to a gateway in the visited PLMN if the homePLMN has selected that the UE should connect to a gateway in the visitedPLMN or/and an address to a gateway in the home PLMN if the home PLMNhas selected that the UE should connect to a gateway in the home PLMN atleast based on the identity of the user of the UE. It should be notedthat the means for including may also be able to include an identity ofthe visited PLMN.

The present invention also relates to a method in a PLMN for selecting agateway to which to connect a UE located in an access network connectedto a visited PLMN of a user of the UE, wherein the PLMN is a home PLMNof the user of the UE. The method is illustrated in FIG. 8 a andcomprising the steps of receiving a first FQDN 801, wherein the firstFQDN comprises an identity of the user of the UE and the home PLMN isaware of an identity of the visited PLMN, and the further steps ofselecting 802 based on the received identity of the user whether the UEshould establish connection only to a gateway in the home PLMN, only toa gateway in the visited PLMN or to both a gateway in the home PLMN anda gateway in the visited PLMN, Transmitting 803 an address belonging toa gateway in the visited PLMN if connection only to a gateway in thevisited PLMN is selected or an address belonging to a gateway in thehome PLMN if connection only to a gateway in the home PLMN is selectedor addresses belonging to both a gateway in the home PLMN and a gatewayin the visited PLMN if connection to both is selected.

The present invention also relates to a method in a UE for determining agateway to connect to, wherein the UE is located in an access networkconnected to a visited PLMN of a user of the UE and the user of the UEbelongs to a home PLMN. The method is illustrated in the flowchart ofFIG. 5 b and comprising the steps of including 804 a first FQDN thatcomprises a domain name belonging to the home PLMN into a DNS request,including 805 an identity of the user of the UE into the first FQDN, andreceiving 806 an address to a gateway in the visited PLMN if the homePLMN has selected that the UE should connect to a gateway in the visitedPLMN or/and an address to a gateway in the home PLMN if the home PLMNhas selected that the UE should connect to a gateway in the home PLMN atleast based on the identity of the user of the UE.

The general procedure is further illustrated in FIG. 2. The UE sends aDNS request to the DNS server in the WLAN access network in order toresolve the FQDN it has constructed (denoted FQDN_(HPLMN) in FIG. 2).The WLAN access network DNS server, which cannot resolve the specialFQDN itself, forwards the request to the HPLMN.

The HPLMN extracts the user ID and the W-APN from the received FQDN tobe input data to the policy decision. In the embodiment in which theVPLMN ID is included in the FQDN the HPLMN extracts the VPLMN ID too. Inthe embodiment in which the VPLMN ID is not included in the FQDN theHPLMN checks the data stored during the preceding network accessprocedure, e.g. in the AAA server, to find out which the concerned VPLMNis (provided that the HPLMN needs this information for the policydecision and/or the DNS processing). In both embodiments the HPLMN thendecides whether home tunneling or local breakout should be used.

If home tunneling is selected, the HPLMN returns one or more PDGh/TTGhaddresses. If local breakout is chosen, the HPLMN constructs an FQDN(denoted FQDN_(VPLMN) in FIG. 2) using the W-APN Network Identifier andthe VPLMN ID as the Operator Identifier (i.e. the same kind of FQDN thatthe UE would construct in the existing solution for local breakout) andsends a DNS request to the VPLMN to resolve it. The VPLMN returns one ormore PDGv/TTGv addresses) which the HPLMN includes in its DNS responsetowards the WLAN access network and the UE. The HPLMN may avoid sendingthe DNS request to the VPLMN, if it has cached data for the concernedFQDN from a previous response from the VPLMN or if the HPLMN hasconfigured PDGv/TTGv addresses) for the concerned VPLMN. The DNSresponse from the HPLMN should have a lifetime (Time-to-Live, TTL) setto zero, indicating that the response is valid during the time zero(i.e. only for this particular request), in order to avoid that the DNSserver in the WLAN access network (or another possibly presentintermediate DNS server) or the DNS resolver in the UE caches theFQDN-IP address mapping (which could eliminate the HPLMN's possibilityto make a (different) policy decision in a subsequent resolution of thesame FQDN). A “DNS resolver” is the DNS software in a host (e.g. theUE/terminal) that forms an interface between applications and the DNSinfrastructure.

When the UE has received the PDG/TTG addresses), it can proceed with theIPsec tunnel establishment in the regular manner.

In FIG. 3 and FIG. 4 the signaling sequence diagram for the modified DNSprocedure is slightly more detailed, since the HPLMN DNS server isseparated from other involved HPLMN entities. (Although depicted anddescribed as a single entity, the HPLMN DNS server may be multiple DNSservers responsible for different parts of the HPLMN's domain namespace, in line with the distributed nature of the DNS system ingeneral.) When the HPLMN DNS server is separated the general procedurediverges into two sub-variants, one of which is illustrated in FIG. 3and the other is illustrated in FIG. 4. In both sub-variants the HPLMNDNS server consults the AAA server and/or a policy server in order toget a home tunneling/local breakout decision and to eventually resolvethe FQDN.

In FIG. 3 the AAA server/policy server not only makes the hometunneling/local breakout decision, it also retrieves/chooses the PDG/TTGaddresses) and returns the address(es) to the HPLMN DNS server. The AAAserver and the policy server may be a single entity or separateentities. In the home tunneling case PDGh/TTGh addresses are configuredinternally in the HPLMN, but in the local breakout case the PDGv/TTGvaddress(es) must be retrieved from the VPLMN (unless the address(es) arecached or configured in the HPLMN). To do this the AAA server/policyserver constructs the above-described FQDN_(VPLMN) and resolves itthrough a regular DNS procedure. Then the AAA server/policy server sendsthe PDGv/TTGv address(es) to the HPLMN DNS server.

In FIG. 4 the interaction between the HPLMN DNS server and the AAAserver/policy server is different. The AAA server/policy server returnsan indication of the policy decision (i.e. home tunneling or localbreakout), but not necessarily any address. In the home tunneling casethe AAA server/policy server may return one or more PDGh/TTGhaddress(es), but it is also possible that these addresses are configuredin the HPLMN DNS server. In the local breakout case the AAAserver/policy server may return only an indication of the policydecision and let the HPLMN DNS server do the rest (i.e. constructing theFQDN_(VPLMN) and retrieving the corresponding PDGv/TTGv address(es) fromthe VPLMN, unless the address(es) is/are already cached in the HPLMN DNSserver). This however requires that the variant with the VPLMN IDincluded in the FQDN_(HPLMN) is used. If the VPLMN ID is not included inthe FQDN_(HPLMN), the AAA server/policy server must return the VPLMN IDor possibly the entire FQDN_(VPLMN) (depending on how you wish todistribute the intelligence between the HPLMN DNS server and the AAAserver/policy server). Also in this case the HPLMN DNS server retrievesthe PDGv/TTGv addresses) from the VPLMN, unless the address(es) is/arealready cached in the HPLMN DNS server.

The alias—canonical name (CNAME) feature of DNS (see P. Mockapetris,“DOMAIN NAMES—CONCEPTS AND FACILITIES”, RFC 1034, November 1987) canalso be used. Then the HPLMN would not itself retrieve the PDGv/TTGvaddress(es) in the local breakout case. Instead the HPLMN DNS serverwould return a CNAME resource record in its response, including an FQDNto be used instead of the FQDN in the original DNS request. The returnednew FQDN would be the FQDN_(VPLMN) that is constructed using the W-APNNetwork Identifier and the VPLMN ID as the Operator Identifier (i.e. thesame kind of FQDN that the UE would construct in the existing solutionfor local breakout). Since the FQDN_(VPLMN) indicates the VPLMN, theaccess network DNS server sends a new request to the VPLMN DNS server tohave the FQDN_(VPLMN) resolved. (It is possible to send the DNS responsewith the FQDN_(VPLMN) (included in a CNAME resource record) all the wayto the UE and let the DNS resolver in the UE restart the DNS requestwith the new FQDN. This would not make any difference to the principlesof the solution, so since the usual DNS behaviour is not to send a CNAMEresponse to the host (unless the host explicitly asked for a CNAMEresponse), it is assumed in this description that the access network DNSserver restarts the DNS request using the received FQDN_(VPLMN). It isalso conceivable that other DNS servers, e.g. another DNS server ownedby the HPLMN operator, have been consulted before reaching the HPLMN DNSserver, and that one of these DNS servers, in case the DNS recursivemode is used, receives the DNS response with the FQDN_(VPLMN) andrestarts the DNS request with the new FQDN instead of sending theFQDN_(VPLMN) to the access network DNS server. However, it is chosen toillustrate only what is regarded as the most interesting case.) TheVPLMN DNS server responds with one or more PDGv/TTGv IP address(es) andthe access network DNS server forwards the response to the UE. When theUE has received the PDG/TTG address(es), it can proceed with the IPsectunnel establishment in the regular manner. FIG. 5 and FIG. 6 illustratethe message flows for this variant in the local breakout case. (Sincethe CNAME feature would only be used in the local breakout case, FIG. 2,FIG. 3, FIG. 4 still apply to the home tunneling case.)

Thus the arrangement illustrated in FIG. 7 comprises according toanother aspect means for selecting 902 based on the received identity ofthe user that the UE should establish connection only to a gateway inthe visited PLMN, means for transmitting 903 by a home PLMN DNS server aCNAME resource record comprising a third FQDN to be used instead of thefirst received FQDN and to be sent to a visited PLMN DNS server, wherebythe third FQDN is constructed by means of a W-APN network identifier andthe identity of the visited PLMN, such that the visited PLMN DNS servercan send a gateway address to the UE by resolving the third FQDN.

FIG. 5 illustrates the procedure when the CNAME feature is used in thelocal breakout case. It shows how the HPLMN returns the FQDN_(VPLMN), sothat the access network DNS server can restart the DNS request with thenew FQDN, i.e. retrieve the PDGv/TTGv address(es) from the VPLMN DNSserver.

In FIG. 6 the DNS server and the AAA server/policy server in the HPLMNare shown separately, malting the message sequence diagram slightly moredetailed than in FIG. 5. The AAA server/policy server may return only anindication of the policy decision and let the HPLMN DNS server constructthe FQDN_(VPLMN). This however requires that the embodiment with theVPLMN ID included in the FQDN_(HPLMN) is used. If the VPLMN ID is notincluded in the FQDN_(HPLMN), the AAA server/policy server must returnthe VPLMN ID or possibly the entire FQDN_(VPLMN) (depending on how youwish to distribute the intelligence between the HPLMN DNS server and theAAA server/policy server).

The example message sequences in this section all assume that the DNSrecursive mode is used, which is common practice. If the non-recursive(iterative) mode were used, the HPLMN DNS server would have to use theCNAME feature in the local breakout case to return the FQDN_(VPLMN)(i.e. the FQDN that the UE would construct if selecting local breakoutin the existing solution), which could then be included in a second DNSrequest from the UE (or the access network DNS server) Alternatively,the HPLMN DNS server could override the non-recursive indication andretrieve the PDGv/TTGv addresses) from the VPLMN DNS server anyway.Other than this, use of the DNS non-recursive mode would only change thesequence of DNS messages, but the principles of the solution wouldremain the same.

As stated above, the present invention is described in the context ofI-WLAN. Extensions and variations in the I-WLAN context are alsopossible according to embodiments of the present invention.

The concept of including the user ID in the FQDN may also be used toensure that for a given user, all tunnels towards W-APNs served from thesame GGSNs should be directed to the same TTG. With this concept theHPLMN has access to both the W-APN and the user ID, when allocating theTTG address via DNS. Thus the HPLMN can ensure that the same TTG isallocated when required as described above.

The intelligence providing this coordination can be placed in the HPLMNDNS server or in the AAA server/policy server in the HPLMN. This willhowever only work when the TTG is allocated in the HPLMN, i.e. a TTGh.To work when the TTG is allocated in the VPLMN, i.e. a TTGv, thesolution has to be extended so that the user ID can be included in theFQDN that is sent in the DNS request to the VPLMN DNS server too. Thenthe VPLMN can perform the same per-user coordination as the HPLMN andensure that the same TTGv is allocated when required.

The solution can be extended to support simultaneous local breakout andhome tunneling according to an embodiment, even for the same W-APN. Thiswould improve the flexibility of the HPLMN's control of the trafficstreams, increasing the granularity of the control means from the rathercoarse per W-APN basis.

The use of simultaneous local breakout and home tunneling should be adecision made by the HPLMN. Packet filters are used to control whatpackets that are sent through the respective tunnels. To indicate to theUS that simultaneous local breakout and home tunneling is to be used theHPLMN returns both one or more PDGh/TTGh addresses) and one or morePDGv/TTGv address(es) in response to the DNS request. Alternatively, theHPLMN returns one or more PDGh/TTGh address(es) and a CNAME record thatcan be resolved into one or more PDGv/TTGv address(es) through anotherDNS request. Possibly the order of occurrence of PDGh/TTGh and PDGv/TTGvcould indicate whether home tunneling or local breakout should be thedefault mechanism for packets that do not match any packet filter.

For a certain W-APN, the choice of local breakout or home tunneling(when both are used simultaneously) for a packet sent from the UE may bebased on packet filters according to one embodiment. The packet filtersmay be based on parameters such as: IP source address, IP destinationaddress, Transport protocol (e.g. TCP or UDP), i.e. the protocol numberfield in IPv4 or the next header field in IPv6, Source port number,Destination port number, Ape of service (TOS) (IPv4), Traffic class(IPv6).

The packet filters may be of the same or similar format as the TrafficFlow Templates (TFTs) specified for GPRS/UMTS (see 3GPP TS 23.060v6.8.0, “3^(rd) Generation Partnership Project; Technical SpecificationGroup Services and System Aspects; General Packet Radio Service (GPRS);Service description; Stage 2 (Release 6)), but other formats serving asimilar purpose would also do. It should also preferably be possible tospecify relative packet filters in the sense that its parameters arespecified in relation to dynamic parameters related to the UE and thepresent traffic flows, e.g. the destination address and the UE IPaddress used as the source address. For instance, a packet filter couldstate that a packet that has a destination address in the same addressrange as the IP address the UE has received from the VPLMN should besent using local breakout.

Similar/corresponding packet filters could also be sent to thePDGh/TTGh, the PDGv/TTGv and/or the WAG through the AAA infrastructure(as described above), so that the HPLMN and the VPLMN can police thetraffic streams through the respective tunnels.

The packet filters governing the traffic flows can be conveyed to the UEin several ways. The easiest way is through configuration of the USIMapplication on the UICC. These configurations may be stored atsubscription time, but it would also be possible for the HPLMN to updatethem dynamically using the available mechanisms for “over the air”modification of data on the UICC. Configuring the packet filters in theterminal equipment (outside the UICC) would also be possible, but lesspreferable, because then the packet filters would be tied to theterminal device instead of the subscriber.

A more advanced method than configuration is to dynamically convey thepacket filters when needed. The various means for this may include: EAPduring UE-PDG/TTG IPsec tunnel establishment, EAP during WLAN accessauthentication, DNS, and Separate retrieval.

The packet filters may be conveyed by using Extensible AuthenticationProtocol (EAP) during UE-PDG/TTG IPsec tunnel establishment. Thus thepacket filters can be piggy-backed on the EAP packets, utilizing amechanism for generic data transfer through EAP. This generic datatransfer mechanism may be the generic container attribute or any of themeans for generic data transport that exist in various EAP methods. Theterm generic container attribute is further described in the publishedinternational applications WO2004/112348, WO2004/112349 andWO2004/112347.

The packet filters conveyed through this method may be used to identifythe packets that are to be passed through the tunnel, whoseestablishment process the EAP procedure is associated with. In addition,the packet filters may be accompanied by an indication of whether thistunnel is the default tunnel for the concerned W-APN.

This means that there will be two transfers of packet filters, whensimultaneous local breakout and home tunneling is used, one associatedwith each tunnel establishment.

The packet filters can also be piggybacked on EAP packets, using thesame mechanisms as mentioned above, during the user authenticationassociated with WLAN network access. In this case the HPLMN does not yetknow what W-APN the UE will use in its subsequent UE-PDG/TTG tunnelestablishment request. Therefore the HPLMN has to include packet filtersassociated with all W-APNs that are included in the user's subscription.

In addition, DNS may also be used to convey packet filters from theHPLMN to the UE, when the UE attempts to resolve an FQDN into one ormore PDG/TTG address(es). In this case the HPLMN knows the concernedW-APN, so only the packet filters associated with the concerned W-APNneed to be transferred.

The DNS TXT resource records (see P. Mockapetris, “DOMAINNAMES—IMPLEMENTATION AND SPECIFICATION”, RFC 1035, November 1987), whichinclude text strings, may be used to convey packet filters. Awell-defined format for the packet filter definitions would have to beused internally in the TXT resource records, but this format would beunknown to the DNS system. The structured use of TXT resource recordssuggested in R. Rosenbaum, “Using the Domain Name System To StoreArbitrary String Attributes”, RFC 1464, May 1993 may be used whendefining the packet filter definition format.

Another way would be to define a new DNS resource record for thispurpose. The new resource record would not have to be widely adoptedoutside the 3GPP sphere, since unknown resource records are handledtransparently by the DNS system. It could even be a proprietarymechanism that is implemented only in an HPLMN and in the terminalsoftware of its subscribers.

Although more delay is introduced it is possible to introduce a separateprocedure for dynamic retrieval of packet filters. The UE could retrievethe packet filters from the HPLMN e.g. using the HyperText TransferProtocol (HTTP) (preferably protected by Transport Layer Security (TLS),Secure Sockets Layer (SSL) or Secure HTTP (S-HTTP)). The UniformResource Identifier (URI) to use in the HTTP request could be acombination of a preconfigured part and a dynamic part, the dynamic partincluding the W-APN, the user ID and possibly the VPLMN ID (if the VPLMNID is not included the HPLMN has to consult its AAA server to retrievethe VPLMN ID). If the packet filters are retrieved for one tunnel at atime (i.e. separate retrieval procedures for the packet filters for thelocal breakout tunnel and the packet filters for the home tunnel), thenthe URI should also include an indication of whether the requestconcerns the local breakout tunnel or the home tunnel. This indicationmay either belong to the configured part (in which case two part URIsneed to be configured in the USIM, one for each tunnel).

To avoid configuring any part of the URI in the USIM the URI may betransferred from the HPLMN to the UE prior to the retrieval of thepacket filters. The HPLMN could transfer either the full URI or only thepart of the URI that is non-session specific (i.e. excluding the W-APN,the user ID, the VPLMN ID and possibly the local breakout tunnel/hometunnel indicator). The local breakout tunnel/home tunnel indicator couldbe seen as a session specific part of the URI, in which case it may beadded by the UE to a retrieved non-session specific part of the URI.However, it could also be seen as a non-session specific part of theURI, in which case it would be included in the part of the URI that isconveyed from the HPLMN. The latter case has the advantage that the UEdoes not have to be aware of whether an IPsec tunnel it is establishingis a local breakout tunnel or a home tunnel.

The full or non-session specific part of the URI may be conveyed to theUE using any of the above described mechanisms for transferring thepacket filters.

If the full or non-session specific part of the URI is conveyed usingEAP during the UE-PDG/TG IPsec tunnel establishment, then the subsequentpacket filter retrieval would only return packet filters that areassociated with the concerned tunnel. Consequently the URI has toinclude a local breakout tunnel/home tunnel indication, which either istransferred from the HPLMN or added by the UE. The full or non-sessionspecific URI could be conveyed using a means for generic data transportin EAP or, in case Protected Extensible Authentication Protocol version2 (PEAPv2) is used, the URI TLV (where TLV denotes a type-length-valueencoded attribute).

If the full or non-session specific part of the URI is conveyed usingEAP during the WLAN access authentication procedure, the concernedtunnels have not been established yet. Consequently, the informationconveyed from the HPLMN must be sufficient for the UE to construct therequired URIs for any of the W-APNs that the user subscribes to (and forboth the local breakout tunnel and the home tunnel). That is, if theHPLMN transfers full URIs, it has to transfer either one URI for eachsubscribed W-APN (if packet filters for both a local breakout tunnel anda home tunnel can be retrieved in a single procedure) or two URIs foreach subscribed W-APN, one for each tunnel (if the packet filters are tobe retrieved separately for each tunnel).

If the HPLMN transfers only part URIs, there are three cases. If asingle procedure is used to retrieve packet filters for both a localbreakout tunnel and a home tunnel, then the HPLMN only needs to transfera single non-session specific URI part. If packet filters are retrievedfor one tunnel at a time, the HPLMN may either transfer two part URIs,one for local breakout tunnels and one for home tunnels, or transfer asingle non-session specific URI part and leave to the UE to add thelocal breakout tunnel/home tunnel indicator.

When EAP is used to convey URIs or part URIs, then the full ornon-session specific URI could be conveyed using either a means forgeneric data transport or, in case PEAPv2 is used, the URI TLV.

If DNS is used to convey URIs or part URIs, the HPLMN acts differentlydepending on whether the packet filters for a local breakout tunnel anda home tunnel are retrieved in a single procedure or separateprocedures. If a single procedure is used, then the HPLMN transferseither a single full URI or a single non-session specific URI part. Ifseparate retrieval procedures are used, the HPLMN may transfer two fullURIs (one for each tunnel), two URI parts (one for each tunnel, i.e.including local breakout tunnel/home tunnel indicators) or a single URIpart, leaving to the UE to add the local breakout tunnel/home tunnelindicator.

A more advanced type of packet filter could consider not onlycharacteristics of the packet itself, but also the time (e.g. time ofday or day of week), referred to as time sensitive packet filters. Tineinformation would then accompany each time sensitive packet filter toindicate the time periods when the packet filter is valid.

Alternatively, instead of including the time information with the packetfilter instructions, the HPLMN could simply modify the packet filters inthe UE and in the concerned PLMN nodes (if the similar/correspondingpacket filters are used in PLMN nodes) when needed in order to achievetime sensitive packet filtering. In this case the HPLMN needs a way tocommunicate with the UE that is always available when the UE isconnected to a WLAN access network. The only one of the above describedcommunication means that fulfils this criterion is packet filterconfiguration in the USIM application with “over the air” modificationfrom the HPLMN. To modify the packet filters in the PLMN nodes (ifneeded) the HPLMN can use the AAA infrastructure and the active AAAsessions for the concerned user.

The above described usage of packet filters to control the trafficduring simultaneous local breakout and home tunneling can be extended tosupport the WLAN Direct IP Access scenario simultaneously with hometunneling and/or local breakout. The HPLMN would then transfer packetfilters to the UE, not only to control what packets that should be sentusing home tunneling or local breakout, but also packet filterscontrolling what packets that should be sent using WLAN Direct IPAccess.

The choice of local breakout or home tunneling is controlled by theHPLMN. However, it may be desirable to allow also the user to influencethe choice, or at least express preferences in the matter by indicatingthe user preference in the DNS request. In the basic solution the user'sonly way to influence the decision is through a possible user profilethat the HPLMN may include as a part of the input data to its decision.There is no dynamic per-session mechanism to express preferences.

A way to improve the user's possibilities to influence the localbreakout/home tunneling decision with a more dynamic means is to let theuser optionally include a preference indication in the FQDN, i.e. anindication of whether the user prefers local breakout or home tunnelingfor the concerned session. The HPLMN extracts the preference indication(if present) along with the user ID and possibly the VPLMN ID and usesthe preference indication as a part of the input data to the localbreakout/home tunneling decision.

The preference indication could e.g. consist of the letter “L”,indicating that local breakout is preferred, or “H””, indicating thathome tunneling is preferred. The letter could be preceded by a dedicatedstring, e.g. “pppp-” that indicates the presence of the optionalpreference indication in the FQDN, such that the complete format of thepreference indication would be “pppp-X”, where “X”, stands for either“L” or “H”.

The location of the preference indication in relation to the user ID andthe possible VPLMN ID in the FQDN is not important. The FQDN format (inthe embodiment with the VPLMN ID included) could be e.g. <userID>.<VPLMN ID>.<preference indication>.<regular home FQDN> or <userID>.<delimiter string>.<VPLMN ID>.<delimiter string>.<preferenceindication>.<delimiter string>.<regular home FQDN>. If the preferenceindication is as easily identified as the delimiter string, then thedelimiter strings preceding and following the preference indication inthe latter FQDN format example are not needed.

Including a user preference indication in the FQDN introduces a newsecurity threat to the DNS procedure, namely that the preferenceindication is maliciously modified before reaching the HPLMN. Thereforeintegrity protection of the user preference indication would bepreferable.

The DNSSEC Security Extensions (DNSSEC) (e.g. described in R. Arends etal., “DNS Security Introduction and Requirements”, RFC 4033, March 2005)do not offer protection of DNS requests—only responses—but neverthelessDNSSEC could be used to indirectly achieve desired protection. If theHPLMN uses DNSSEC to integrity protect its DNS response to the UE andincludes the received preference indication, e.g. in a TXT resourcerecord, in the protected response, then the UE can verify that the HPLMNdid indeed receive the correct preference indication. If the returnedpreference indication differs from the one the UE sent to the HPLMN,then the UE should preferably discard the received PDG/TTG address.

Another way to protect the preference indication is to leverage thecryptographic material produced during the preceding WLAN accessauthentication procedure (provided that the optional accessauthentication was performed). The cryptographic material could consistof e.g. the CK, the IK, the MSK or the EMSK produced during the EAP-AKAprocedure (or corresponding cryptographic material produced during theEAP-SIM procedure). The UE uses this cryptographic material to constructa Message Authentication Code (MAC) that is added to the FQDN. Theformat of the FQDN (in the embodiment with the VPLMN ID included) wouldthen be e.g. <MAC>.<user ID>.<VPLMN ID>.<preference indication>.<regularhome FQDN> or <MAC>. <delimiter string>.<user ID>. <delimiter string>.<VPLMN ID>. <delimiter string>.<preference indication>.<delimiterstring>.<regular home FQDN>. If the preference indication is as easilyidentified as the delimiter string, then the delimiter strings precedingand following the preference indication in the latter FQDN formatexample are not needed. Similarly, if the HPLMN always knows whether aMAC is included in the FQDN, then the delimiter string between the MACand the user ID is not needed. The input data to the MAC, i.e. the datathat is protected by the MAC, could be only the preference indication,the whole FQDN, the entire DNS request, or anything in between.

If no preceding WLAN access authentication was performed, a possibleworkaround could be to let the UE generate one or more random number(s),which is(are) fed into the GSM authentication algorithm executing in theSIM. The produced cryptographic material can then be used to generate aMAC as described above. The KC or the IK is then used to generate a MACas described above. However, in this case the UE also includes thegenerated random number in the FQDN in order for the HPLMN to be able toderive the same cryptographic material and verity the MAC. The format ofthe FQDN (using the variant with the VPLMN ID included) could be e.g.<random number>.<MAC>.<user ID>.<VPLMN ID>.<preferenceindication>.<regular home FQDN> or <random number>.<MAC>.<delimiterstring>.<user ID>.<delimiter string>.<VPLMN ID>.<delimiterstring>.<preference indication>.<delimiter string>.<regular home FQDN>.As described before, the delimiter strings preceding and following thepreference indicator, as well as the delimiter string following the MAC,may not be needed.

Yet a way to battle the security threat would be to let the UE send thepreference indication to the HPLMN in a secure manner during theauthentication procedure associated with the IPsec tunnel establishment(in addition to sending it unprotected in the DNS request). Then theHPLMN can verify that the preference indication received through DNS wascorrect. Secure transfer of the preference indication between the UE andthe HPLMN could be achieved via the generic data transfer means in EAPmethods.

In a possible alternative solution (as applied to the current I-WLAN) anoperator's policies regarding the choice between home tunneling andlocal breakout are the same for all subscribers and instead depend onlyon the VPLMN and/or the W-APN. In such case, a variation of the solutionis that the user/UE includes only the VPLMN ID, but not the user ID, inthe FQDN, resulting in the format <VPLMN ID>.<regular home FQDN> or<VPLMN ID>.<delimiter string>.<regular home FQDN>.

The HPLMN would extract the VPLMN ID from the received FQDN and base itschoice of home tunneling or local breakout entirely on the VPLMN IDand/or the W-APN. If local breakout is chosen, the HPLMN proceeds asdescribed above in the basic solution for the current I-WLAN, i.e. itconstructs an FQDN using the W-APN Network Identifier and the VPLMN IDas the Operator Identifier and sends a DNS request to the VPLMN toresolve it.

The solution, as described for I-WLAN, is not limited to WLAN accessnetworks, but may also be used in conjunction with any non-3GPP accessnetwork that interworks with 3GPP PLMNs. This is possible, because thetunneling solution that is used in I-WLAN (or a similar solution), whichis a prerequisite for this application of the inventive solution, may beused for access via any type of non-3GPP access network.

The basic solution and its possible extensions have so far beendescribed in terms of the current 3GPP I-WLAN architecture. The solutioncan however advantageously be applied also in the above describedevolved network architectures (see FIG. 1 b and FIG. 1 c).

Moreover, the solution can be generalized and applied also to I-WLAN inthe envisioned evolved 3GPP network architecture as of FIG. 1 b (i.e.the architecture including the AENs) as well as possible intermediatestages.

In the evolved network architecture of FIG. 1 b PDGh/TTGh and PDGv/TTGvshould be replaced by AENH and AENv in the solution. Possibly the UE-AENtunnel should always end in the AENv, when the UE is roaming in theevolved network architecture, with other mobility mechanisms handlingthe AENv-AENh part in the home tunneling case.

In possible intermediate evolutionary stages the local breakout tunnelmay terminate in the WAG or in the GSN+ in the VPLMN, but otherwise theprinciples of the solution would be the same.

When applying the solution to the selection of an AEN in the consideredevolved network architecture of FIG. 1 b, there are two importantdifferences from the selection of a PDG/TTG in the current I-WLAN tokeep in mind, both stemming from the anticipated role of the AEN:

-   -   The AEN has to be selected before the UE has received an IP        address (because the AEN is the entity that is assumed to        allocate the IP address).    -   The AEN has to be selected before the access authentication,        i.e. before the HPLMN has been involved in any user        authentication procedure (because the AEN is assumed to perform        the access authentication, e.g. acting as an EAP Authenticator        (in pass-through mode)).

However, despite these differences the basic concept of the solution canbe reused, as explained below.

The basic concept of the solution, i.e. including the user identity andpreferably the VPLMN ID and/or a service related identifier in an FQDNto be resolved by DNS, may be reused in the context of AEN selection inthe long-term evolved network architecture depicted in FIG. 1 b.

The UE will probably not receive an IP address before an AEN isselected. Therefore, since DNS requests require an IP address, the UEcan probably not issue the DNS request itself. However, the accessnetwork could do it on behalf of the UE.

Either the HPLMN or the VPLMN may resolve the DNS request in order toallocate an AEN to the user/UE. This is a design choice. Thus, the DNSrequest could be sent either to the HPLMN (as in the above describedsolution for local breakout in I-WLAN) or to the VPLMN.

The FQDN would include data retrieved from the UE. This is the useridentity and possibly a service related identifier of some kind (whichmay or may not be APN based). Since the AEN will probably perform theuser authentication at network access and since the AEN naturally cannotbe involved before it has been selected, the HPLMN will not be aware ofwhich VPLMN the user is accessing. Therefore, if the DNS request is sentto the HPLMN, the VPLMN ID should also be included in the FQDN. The lastpart of the FQDN should be a domain name indicating the HPLMN, if theDNS request is to be sent to the HPLMN, or a domain name indicating theVPLMN, if the DNS request is to be sent to the VPLMN.

It is conceivable that the UE could acquire an IP address before the AENis allocated, e.g. a temporary IP address allocated by the accessnetwork. If so, using this IP address the UE could issue the DNS requestitself.

The assumptions for the considered evolved network architecture depictedin FIG. 1 c are somewhat different than for the evolved networkarchitecture in FIG. 1 b. One such difference is that the non-3GPP (andpossibly I-WLAN) access network, in the form of the AGW, is assumed toperform the access authentication, acting as an EAP Authenticator (inpass-through mode). Therefore only one of the differences from thePDG/TTG selection in the current I-WLAN that were listed for AENselection above applies in this context, namely:

The s-IASA has to be selected before the UE has received an IP address.

Since the s-IASA has to be selected before the UE has received an IPaddress, the access network, i.e. the AGW, has to send the DNS requeston behalf of the UE, i.e. similar to the case of AEN selection. However,in contrast to the case of AEN selection, the AGW does not have to sendthe DNS request before the access authentication. Thus, when the DNSrequest is sent, the HPLMN has already been involved in the userauthentication and therefore knows which VPLMN, if any, that isconcerned.

As in the case of AEN selection the DNS request could be sent either tothe VPLMN or to the HPLMN. If the DNS request is sent to the HPLMN, theVPLMN ID may or may not be included in the FQDN, because the option ofutilizing the in the HPLMN already available information about theconcerned VPLMN (retrieved during the user authentication) is available,just as for PDG/TTG selection in the current I-WLAN. Whether sent to theVPLMN or the HPLMN, the FQDN could include a service related identifier,e.g. the Communication Service Identifier (CSI) or an APN-basedidentifier.

In any case, the last part of the FQDN should be a domain nameindicating the HPLMN, if the DNS request is to be sent to the HPLMN, ora domain name indicating the VPLMN, if the DNS request is to be sent tothe VPLMN.

If the solution is used for control of simultaneous local breakout andhome tunneling, similar to what is described above, the CSI could beused as an alternative, or addition, to packet filters as a criterionwhen choosing between local breakout and home tunneling for a certaintraffic flow.

A possible variation, although not preferable, is that the AGW couldsend the DNS request before performing the access authentication, whichwould make s-IASA selection very similar to AEN selection and wouldrequire that the VPLMN ID be included in the FQDN, if the DNS request issent to the HPLMN.

If a UE potentially can access multiple IASAs from its point of access,then s-IASA selection is applicable also in the non-roaming case, i.e.when no VPLMN is involved. This can be seen as a special case of theabove-described procedure for s-IASA selection. In this case neither theVPLMN ID nor local breakout is applicable. The FQDN would contain theuser identity and possibly a service related identifier in addition tothe domain name indicating the HPLMN.

Note also that in the 3GPP SAE architecture it is still unsettledwhether the AAA server is a stand-alone entity or integrated in the HSS.The latter approach is currently the working assumption for the evolvedarchitecture depicted in FIG. 1 c.

The present invention can also be applied to the selection/allocation ofHome Agent in the evolved network architecture depicted in FIG. 1 c. Inthe current view of this considered evolved network architecture the HAis allocated directly to the UE using DNS, at least in the case of anon-3GPP (and possibly I-WLAN) access being used. This application ofthe invention can hence be very similar to the application of theinvention as described for PDG/TTG selection in the current I-WLAN. Asin the case of PDG/TTG selection a HA could be allocated in either theHPLMN or the VPLMN (with the HPLMN assumedly being the most commonlyused option).

A difference from the current I-WLAN (and the current networkarchitecture in general) is that the APN concept will not necessarily bereused in the SAE architecture. It cannot be ruled out, but it is morelikely that it is not going to be used. However, an identifier that mayserve a similar purpose in the context of this solution is theCommunication Service Identifier (CSI).

If the APN concept is reused, then the UE would construct its “regularhome FQDN” in the same way as described above. Otherwise the regularhome FQDN would consist simply of a domain name belonging to the homePLMN, e.g. <home-operator>.com. The regular home FQDN can then beextended in various ways, similar to what was described above, with auser-ID and a VPLMN ID (e.g. in the shape of a domain name or acombination of a Mobile Country Code (MCC) and a Mobile Network Code(MNC)). The resulting FQDNs are:

<user ID>.<regular home FQDN> or <user ID>.<delimiter string>.<regularhome FQDN> <user ID>.<VPLMN ID>.<regular home FQDN> or <userID>.<delimiter string>.<VPLMN ID>.<delimiter string>.<regular home FQDN>

In addition, the CSI, or some other service related identifier(henceforth abbreviated SRI), may be included in the FQDN to providefurther information to the HPLMN. The CSI or service related identifiercould be included in the FQDN e.g. before the regular home FQDN,resulting in the following special FQDNs:

<user ID>.<CSI or SRI>.<regular home FQDN> or <user ID>.<delimiterstring>.<CSI or SRI>.<delimiter string>.<regular home FQDN> <userID>.<VPLMN ID>.<CSI or SRI>.<regular home FQDN> or <user ID>.<delimiterstring>.<VPLMN ID>.<delimiter string>.<CSI or SRI>.<delimiterstring>.<regular home FQDN>

If a service related identifier (CSI or SRI) is already a part of theregular home FQDN, then an additional inclusion of this identifierbefore the regular home FQDN is of course redundant and should not beused.

Extraction of the relevant data from the extended FQDN, the interactionbetween DNS servers (in the access network, the HPLMN and the VPLMN) andthe interaction between the DNS servers and the AAA server and/or policyserver are performed in the same way as described above for the presentinvention's application to PDG/TTG selection in the current I-WLAN(substituting the CSI or SRI for the W-APN and HA for PDG/TTG whenapplicable).

Most of the possible extensions of the solution that are described inthe I-WLAN context are applicable to HA allocation in the consideredevolved network architecture of FIG. 1 c too, sometimes with minoradaptations.

The simultaneous local breakout and home tunneling extension isapplicable. If local breakout is realized through MIPv6 routeoptimization, then the HPLMN does not have to do anything to enable thefeature, but sending packet filters to the UE allows the HPLMN toexecute some control over which type of traffic that is allowed forlocal breakout and home tunneling respectively. The same means forconveying the packet filters to the UE as described above can be used,but with the EAP procedure for the user authentication for WLAN accessreplaced by the EAP procedure for user authentication in the accessnetwork and the EAP procedure during IPsec tunnel establishment replacedby the EAP procedure in conjunction with UE-HA IPsec securityassociation (SA) establishment (which is however performed lessfrequently). In addition to the examples of packet filter parametersmentioned above, service related parameters, e.g. CSIs or APN-likeparameters may be used. Similar packet filters may be conveyed to theVPLMN, so that the VPLMN can enforce the packet filter rules. The AAAinfrastructure could be used for this, e.g. during the userauthentication procedure in the access network, or an inter-PLMN policycontrol interface.

The extension described above allowing a user to include a preferenceindication in the FQDN, indicating whether home tunneling or localbreakout is preferred, is applicable, but with the EAP procedure for theuser authentication for WLAN access replaced by the EAP procedure foruser authentication in the access network and the EAP procedure duringIPsec tunnel establishment replaced by the EAP procedure in conjunctionwith UE-HA IPsec SA establishment (which is however performed lessfrequently).

The above described variation of using an FQDN without an included userID is applicable, but with the described use of the W-APN generalized toencompass the possibility of replacing the W-APN with other servicerelated identifiers, such as the CSI (which then should be included inthe FQDN).

Although the target mobility protocol for the above described method forHA allocation is Mobile IPv6, the same method can be used for allocationof a Mobile IPv4 HA.

It will be understood by those skilled in the art that variousmodifications and changes may be made to the present invention withoutdeparture from the scope thereof, which is defined by the appendedclaims.

1-35. (canceled)
 36. An arrangement in a Public Land Mobile Network(PLMN) for selecting a gateway for connecting a User Equipment (UE) to ahome PLMN when the UE is located in an access network connected to avisited PLMN, the arrangement comprising: means for receiving a firstFully Qualified Domain Name (FQDN), wherein the first FQDN includes anidentity of the user of the UE; means for selecting, based on thereceived identity of the user and knowledge of the visited PLMN, whetherthe UE should establish a connection only to a gateway in the home PLMN,only to a gateway in the visited PLMN, or to both a gateway in the homePLMN and a gateway in the visited PLMN; and means for transmitting tothe UE, an address belonging to a gateway in the visited PLMN ifconnection only to a gateway in the visited PLMN is selected, or anaddress belonging to a gateway in the home PLMN if connection only to agateway in the home PLMN is selected, or addresses belonging to both agateway in the home PLMN and a gateway in the visited PLMN if connectionto both is selected.
 37. The arrangement according to claim 36, whereinthe means for selecting includes means for identifying, at least basedon the user identity, one or more valid policies which govern theoutcome of the selecting.
 38. The arrangement according to claim 36,wherein the home PLMN gains knowledge of the identity of the visitedPLMN during an authentication procedure.
 39. The arrangement accordingto claim 36, wherein the first FQDN includes an identity of the visitedPLMN.
 40. The arrangement according to claim 36, wherein the gateway forconnecting the UE to the home PLMN is a Packet Data Gateway/TunnelTerminating Gateway (PDG/TTG).
 41. The arrangement according to claim36, wherein the means for selecting includes means for consulting anauthentication device or a policy server to select whether connection toa gateway in the visited PLMN, connection to a gateway in the home PLMN,or connection to both should be selected.
 42. The arrangement accordingto claim 36, wherein if a connection to a gateway in the visited PLMN isselected, the means for selecting comprises: means for constructing asecond FQDN that indicates the visited PLMN; means for sending thesecond FQDN to the visited PLMN; means for receiving the addressbelonging to the gateway in the visited PLMN at least based on the sentsecond FQDN; and means for transmitting the address belonging to thegateway in the visited PLMN to the UE.
 43. The arrangement according toclaim 42, wherein the means for constructing a second FQDN includesmeans for modifying the first FQDN, said means for modifying the firstFQDN comprising: means for removing the user identity from the firstFQDN; means for removing the identity of the visited PLMN from the firstFQDN if the first FQDN comprises an identity of the visited PLMN; andmeans for replacing an indication of the home PLMN in the first FQDNwith an indication of the visited PLMN.
 44. The arrangement according toclaim 36, wherein the FQDN includes an indication of user preferenceconcerning connection to a gateway in the visited PLMN versus connectionto a gateway in the home PLMN.
 45. The arrangement according to claim37, wherein the valid policies are identified by means of a WLAN-AccessPoint Name (W-APN) included in the FQDN.
 46. The arrangement accordingto claim 36, wherein the means for transmitting includes means fortransmitting the gateway address or addresses in a DNS response.
 47. Thearrangement according to claim 46, wherein the means for transmittingincludes means for setting a Time To Live (TTL) parameter in the DNSresponse to zero.
 48. An arrangement in a User Equipment (UE) fordetermining a gateway for connecting to a Public Land Mobile Network(PLMN), wherein the UE is located in an access network connected to avisited PLMN, and the UE belongs to a home PLMN, the arrangementcomprising: means for including in a Domain Name Server (DNS) request, afirst Fully Qualified Domain Name (FQDN) that comprises a domain namebelonging to the home PLMN; means for including an identity of the userof the UE into the first FQDN; and means for receiving an address to agateway in the visited PLMN if the home PLMN selects that the UE shouldconnect to a gateway in the visited PLMN, or an address to a gateway inthe home PLMN if the home PLMN selects that the UE should connect to agateway in the home PLMN at least based on the identity of the user ofthe UE.
 49. The arrangement according to claim 48, further comprisingmeans for including an identity of the visited PLMN in the first FQDN tomake the home PLMN aware of the identity of the visited PLMN.
 50. Thearrangement according to claim 48, further comprising means forselectively sending data packets utilizing a packet filter either to thegateway in the visited PLMN or to the gateway in the home PLMN.
 51. Thearrangement according to claim 50, wherein the means for selectivelysending data packets utilizing a packet filter selects a gateway basedon at least one of the packet parameters: IP source address, IPdestination address, protocol indicator field in the IP header,transport protocol, source port number, destination port number, type ofservice, and traffic class.
 52. The arrangement according to claim 50,wherein the packet filter is time sensitive.
 53. The arrangementaccording to claim 48, further comprising means for including anindication of user preference concerning connection to a gateway in thevisited PLMN versus connection to a gateway in the home PLMN in theFQDN.
 54. The arrangement according to claim 48, further comprisingmeans for including a WLAN-Access Point Name (W-APN) in the FQDN.
 55. Anarrangement in a Public Land Mobile Network (PLMN) for selecting agateway to which to connect a User Equipment (UE) to a home PLMN whenthe UE is located in an access network connected to a visited PLMN, thearrangement comprising: means for receiving a first Fully QualifiedDomain Name (FQDN), wherein the first FQDN includes an identity of theuser of the UE; means for selecting, based on the received identity ofthe user and knowledge of the visited PLMN, that the UE should establisha connection only to a gateway in the visited PLMN; and means fortransmitting by a home PLMN DNS server, a CNAME resource recordcomprising a third FQDN to be used instead of the first received FQDNand to be sent to a visited PLMN DNS server, wherein the third FQDN isconstructed utilizing a WLAN-Access Point Name (W-APN) networkidentifier and the identity of the visited PLMN, such that the visitedPLMN DNS server can send a gateway address to the UE by resolving thethird FQDN.
 56. An arrangement in a User Equipment (UE) for determininga gateway for connecting to a Public Land Mobile Network (PLMN), whereinthe UE is located in an access network connected to a visited PLMN, andthe UE belongs to a home PLMN, the arrangement comprising: means forincluding in a Domain Name Server (DNS) request, a first Fully QualifiedDomain Name (FQDN) that comprises a domain name belonging to the homePLMN; means for including an identity of the visited PLMN in the firstFQDN; and means for receiving an address to a gateway in the visitedPLMN if the home PLMN has selected that the UE should connect to agateway in the visited PLMN or an address to a gateway in the home PLMNif the home PLMN has selected that the UE should connect to a gateway inthe home PLMN at least based on the identity of the visited PLMN.
 57. Amethod in a Public Land Mobile Network (PLMN) for selecting a gatewayfor connecting a User Equipment (UE) to a home PLMN when the UE islocated in an access network connected to a visited PLMN, the methodcomprising the steps of: receiving a first Fully Qualified Domain Name(FQDN), wherein the first FQDN includes an identity of the user of theUE; selecting, based on the received identity of the user and knowledgeof the visited PLMN, whether the UE should establish a connection onlyto a gateway in the home PLMN, only to a gateway in the visited PLMN, orto both a gateway in the home PLMN and a gateway in the visited PLMN;and transmitting to the UE, an address belonging to a gateway in thevisited PLMN if connection only to a gateway in the visited PLMN isselected, or an address belonging to a gateway in the home PLMN ifconnection only to a gateway in the home PLMN is selected, or addressesbelonging to both a gateway in the home PLMN and a gateway in thevisited PLMN if connection to both is selected.
 58. The method accordingto claim 57, wherein the step of receiving the first FQDN includesreceiving in the first FQDN, an identity of the visited PLMN to make thehome PLMN aware of the identity of the visited PLMN.
 59. The methodaccording to claim 57, wherein the selecting step includes consulting anauthentication device or a policy server to select whether connection toa gateway in the visited PLMN, connection to a gateway in the home PLMN,or connection to both should be selected.
 60. The method according toclaim 57, wherein if a connection to a gateway in the visited PLMN isselected, the selecting step comprises the further steps of:constructing a second FQDN that indicates the visited PLMN; sending thesecond FQDN to the visited PLMN; receiving the address belonging to thegateway in the visited PLMN at least based on the sent second FQDN; andtransmitting the address belonging to the gateway in the visited PLMN tothe UE.
 61. The method according to claim 60, wherein the step ofconstructing a second FQDN includes modifying the first FQDN by:removing the user identity from the first FQDN, removing the identity ofthe visited PLMN from the first FQDN, if the first FQDN comprises anidentity of the visited PLMN, and replacing an indication of the homePLMN in the first FQDN with an indication of the visited PLMN.
 62. Amethod in a User Equipment (UE) for determining a gateway for connectingto a Public Land Mobile Network (PLMN), wherein the UE is located in anaccess network connected to a visited PLMN, and the UE belongs to a homePLMN, the method comprising the steps of: including in a Domain NameServer (DNS) request, a first Fully Qualified Domain Name (FQDN) thatcomprises a domain name belonging to the home PLMN; including anidentity of the user of the UE into the first FQDN; and receiving anaddress to a gateway in the visited PLMN if the home PLMN selects thatthe UE should connect to a gateway in the visited PLMN, or an address toa gateway in the home PLMN if the home PLMN selects that the UE shouldconnect to a gateway in the home PLMN at least based on the identity ofthe user of the UE.
 63. The method according to claim 62, furthercomprising including an identity of the visited PLMN in the first FQDN.64. The method according to claim 62, wherein, when the UE receives anaddress to a gateway in the visited PLMN and an address to a gateway inthe home PLMN, the method further comprises utilizing a packet filter toselectively send data packets from the UE either to the gateway in thevisited PLMN or to the gateway in the home PLMN.
 65. The methodaccording to claim 62, further comprising including in the FQDN, anindication of user preference concerning connection to a gateway in thevisited PLMN versus connection to a gateway in the home PLMN.